Secure Router Authentication

ABSTRACT

A network router may send a self-authenticating message to a plurality of host devices. The self-authenticating message may comprise a router advertisement message and a hash of at least a portion of the router advertisement message. The hash may allow the host devices to authenticate the network router for communications.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of and claims priority to U.S. Pat.Application No. 17/144,863, filed Jan. 8, 2021, which is a continuationof U.S. Pat. Application No. 14/316,406, filed on Jun. 26, 2014 (nowU.S. Pat. No. 10,931,456), each of which is hereby incorporated byreference in its entirety.

BACKGROUND

Among other things, the Internet Protocol (IP) describes discoveryprotocols. As one example, Neighbor Discovery Protocol (NDP) can be usedby nodes to discover each other. For example, the specifications for IPversion 6 (“IPv6”), which is a new version of IP, defines a protocolcalled Neighbor Discovery Protocol (“NDP”). IPv6 nodes (e.g., hosts androuters) use NDP to discover each other, exchange routing information,manage auto-configuration, and perform other tasks important to IPnetworking.

In some implementations, IP nodes implicitly trust NDP messagesgenerated by other nodes. Without any inherent security mechanisms toprovide confidentiality, integrity, or availability, suchimplementations are susceptible to abuse. In addition, although IPSec(Internet Protocol Security) may be used to secure NDP messages, IPSecrequires significant manual configuration and is unwieldy to deploy inlarge environments.

Subsequent efforts, such as SEcure Neighbor Discovery (“SEND”) whichuses public-key cryptography and digital certificates, to secure NDPmessages still have numerous shortcomings. In practice, an effectivedeployment of SEND required a significant investment in Public KeyInfrastructure (“PKI”), which can be cumbersome and costly to operate.As a result, SEND has been met with limited acceptance.

While attempts have been made to add security to NDP, there are numerousdrawbacks that leave room for improvement.

SUMMARY

As described herein, some aspects relate to systems and methodsinvolving secure device authentication using aspects of a zero-knowledgepassword proof approach are disclosed. In one example, a device maygenerate a self-authenticating message including its identity and/or itscapability attributes. The device may use a secret value, random nonce,public ephemeral value (PEV), session key, and/or other values togenerate the self-authenticating message. The secret value may beunknown to a device receiving the self-authenticating message. With theuse of pre-loaded values, including a verifier, the receiving device maycompare its own host-generated keyed-hash message authentication code(“HMAC”) with the router-generated HMAC to verify the authenticity ofthe message. In one example, such authentication may be useful, interalia, on an Internet Protocol (IP) network utilizing NDP.

In one example, aspects may relate to a method involving generating, bya computing device (e.g., wireless router apparatus), aself-authenticating message. The message may include informationrelating the identity and/or capability attributes of the computingdevice. At least portions of the message may be hashed using at least asecret value unknown to self-configurable host apparatuses, whichreceive the message. The self-configurable host apparatuses, uponreceipt of the self-authenticating message, may calculate anauthentication code (e.g., a hashed message authentication code) toauthenticate the message. The host apparatus may use one or more values,such as a public static value, a verifier, a public ephemeral value,and/or other values to calculate the HMAC. The host may compare thegenerated HMAC to the received router’s HMAC to determine if the messageis authentic.

The preceding presents a simplified summary in order to provide a basicunderstanding of some aspects of the disclosure. The summary is not anextensive overview of the disclosure. It is neither intended to identifykey or critical elements of the disclosure nor to delineate the scope ofthe disclosure. The summary merely presents some concepts of thedisclosure in a simplified form as a prelude to the description below.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure is illustrated by way of example and not limitedin the accompanying figures in which like reference numerals indicatesimilar elements and in which:

FIG. 1 illustrates an example information distribution network.

FIG. 2 illustrates an example hardware platform on which the variouselements described herein can be implemented.

FIG. 3 illustrates a system according to one or more aspects of thedisclosure.

FIG. 4 , FIG. 5 , and FIG. 6 illustrate flowcharts according to one ormore aspects of the disclosure.

DETAILED DESCRIPTION

In the following description of various illustrative embodiments,reference is made to the accompanying drawings, which form a parthereof, and in which is shown, by way of illustration, variousembodiments in which aspects of the disclosure may be practiced. It isto be understood that other embodiments may be utilized, and structuraland functional modifications may be made, without departing from thescope of the present disclosure.

Communication protocols exist that use neighbor discovery protocols todiscover networks and/or machines (e.g., hosts and routers). Someneighbor discovery protocols operate using particular message types(e.g., a Router Advertisement message type). A newer version of theInternet Protocol, IPv6, includes a version of NDP that also uses aparticular Router Advertisement (“RA”) message type. However, the NDPdefined for IPv6 provides little in the way of native security; thisleaves IPv6′s RA messages susceptible to abuse and forgery. Whilesolutions like IPSec and SEND have been proposed to improve IPv6′s NDPsecurity, they can be cumbersome and/or difficult to implement and havefailed to gain widespread acceptance.

Systems and methods disclosed herein can be used for authenticating oneor more types of messages communicated between a router and hosts, suchas RA messages (or other message types) sent from a router to hosts.Various derivations of the approaches disclosed herein are alsocontemplated. Specifically, many of the disclosed approaches usevariations of zero-knowledge password proofs (“ZKPP”) and augmentedpassword-authenticated key agreements (“PAKE”) to authenticateparticular kinds of NDP messages, such as RA messages, and other kindsof broadcast/multicast messages. In some examples, aspects of the novelapproach may be referred to as an end-to-end zero-knowledge passwordproof for router authentication (“ZKPPRA”) solution.

Some aspects disclosed herein relate to message-level authentication ascompared to user-level authentication. In addition, some aspectsdescribe the directionality of authentication to be from a centralizedrouter or gateway to one or more hosts (e.g., client computing devices).As such, the authentication protocol may be unidirectional in nature,and may eliminate, in some examples, the need for hosts to providerandom nonces as part of the authentication process. In some examples,static values may be used instead, and hosts may not need to transmitinformation to an authenticating router. The ZKPPRA solution may includeone or more of the aforementioned features.

In one example of a ZKPPRA solution, an authentication mechanism and/orprotocol may undergo some preparations, such as one or more of thefollowing preparatory measures: (1) preparation stage (e.g., routerpreparation to produce authenticated protocol data units (“PDUs”) ormessages); (2) PDU production stage (e.g., production of authenticatedPDUs, for example, a signed IPv6 RA message); and/or (3) PDU validationstage (e.g., validation of authenticated PDUs). In addition, in someexamples of a ZKPPRA solution one or more of the following preparatorymeasures may be taken: (1) standardization on specific key exchangealgorithms and message digest algorithms, (2) definition ofconfiguration parameters for routers, and/or (3) definition ofconfiguration parameters for hosts. Although the preceding examples havedescribed steps of the process in terms of stages, the disclosure is notso limited. Rather, one or more stages may be conflated into anotherstage, may be divided into multiple additional stages, may be performedconcurrently with another stage, or may be optional, as appropriate.

FIG. 1 illustrates an example information distribution network 100 onwhich many of the various features described herein may be implemented.The illustrated information distribution network is only one example ofa suitable network and is not intended to suggest any limitation as tothe scope of use or functionality of the disclosure. The illustratednetwork should not be interpreted as having any dependency orrequirement relating to any component or combination of components in aninformation distribution.

The network 100 may be a telecommunications network, a multi-serviceoperator (MSO) network, a cable television (CATV) network, a cellularnetwork, a wireless network, an optical fiber network, a coaxial cablenetwork, a hybrid fiber-coaxial (HFC) network, or any other suitabletype of information distribution network or combination of networks. Forexample, the network 100 may be a cellular broadband networkcommunicating with multiple communications access points, such as awireless communications tower 130. In another example, the network 100may be a coaxial system comprising a cable modem termination system(CMTS) communicating with numerous gateway interface devices (e.g., agateway interface device 111 in an example home 102 a). In anotherexample, the network 100 may be a fiber-optic service system comprisingoptical fibers extending from an optical line terminal (OLT) to numerousoptical network terminals (ONTs) communicatively coupled with variousgateway interface devices. In another example, the network 100 may be adigital subscriber line (DSL) system that includes a local office 103communicating with numerous gateway interface devices. In anotherexample, the network 100 may be an HFC network in which Internet trafficis routed over both optical and coaxial communication paths to a gatewayinterface device in or near a user’s home. Various aspects of thedisclosure may operate on one or more of the networks described hereinor any other suitable network architectures now known or laterdeveloped.

The network 100 may use a series of interconnected communication links101 (e.g., coaxial cables, optical fibers, wireless links, etc.) toconnect premises such as homes 102 or other user environments to a localoffice 103. The communication links 101 may include any suitable wiredcommunication links, wireless communication links, communicationsnetworks, or combinations thereof. For example, portions of thecommunication links 101 may be implemented with fiber-optic cable, whileother portions of the communication links 101 may be implemented withcoaxial cable. The communication links 101 may also include variouscommunications components such as splitters, filters, amplifiers,wireless components, and other suitable components for communicatingdata. Data may include, for example, internet data, voice data, weatherdata, content data, and any other suitable information. Content data mayinclude, for example, video content, audio content, media on demand,video on demand, streaming video, television programs, text listings,graphics, advertisements, and other content. A content item mayrepresent an individual piece of content, such as a media content item(e.g., a particular movie, television episode, online video clip, song,audio recording, image, or other media content) or any other data. Insome instances, a content item may be fragmented into segments, such asa plurality of two-second video fragments that may be separatelyaddressed and retrieved.

The local office 103 may transmit downstream information signals ontocommunication links 101, and premises such as a home 102 may receive andprocess those signals. In certain implementations, communication links101 may originate from a local office 103 as a single communicationspath, and may be split into any suitable number of communication linksto distribute data to homes 102 and various other destinations. Althoughthe term home is used by way of example, homes 102 may include any typeof user environment, such as single family homes, apartment complexes,businesses, schools, hospitals, parks, and other suitable environmentsand combinations of environments.

The local office 103 may include an interface 104, which may be acomputing device configured to manage communications between devices onthe network of communication links 101 and backend devices, such asserver 105, server 106, and server 107. For example, an interface 104may be a cable modem termination system (CMTS). The termination systemmay be as specified in a standard, such as, in an example of an HFC-typenetwork, the Data Over Cable Service Interface Specification (DOCSIS)standard, published by Cable Television Laboratories, Inc. Thetermination system may be configured to transmit data over one or moredownstream channels or frequencies to be received by various devices,such as modems in homes 102, and to receive upstream communications fromthose modems on one or more upstream frequencies.

The local office 103 may include one or more network interfaces 108 forcommunicating with one or more external networks 109. One or moreexternal networks 109 may include, for example, one or moretelecommunications networks, Internet Protocol networks, cellularcommunications networks (e.g., Global System for Mobile Communications(GSM), Code Division Multiple Access (CDMA), and any other suitable 2nd,3rd, 4th and higher generation cellular communications networks),cellular broadband networks, radio access networks, fiber-opticnetworks, local wireless networks (e.g., Wi-Fi, WiMAX), satellitenetworks, and any other suitable networks or combinations of networks.

The local office 103 may include a variety of servers that may beconfigured to perform various functions. Local office 103 may includeone or more push servers 105 for generating push notifications todeliver data, instructions, or both to devices that are configured todetect such notifications. For example, push server 105 may transmit aninstruction to a device to transfer service from one wireless network orcommunications access point to another wireless network orcommunications access point. Local office 103 may include one or moreserver computing devices (e.g., content servers 106) configured toprovide content (e.g., media content) to devices. Local office 103 mayinclude one or more application servers 107. For example, applicationserver 107 may be used to implement a caching device, such as a cacheserver, for the content stored in or provided by content server 106.

Homes 102 may include a single family home, an apartment, a restaurant,an office suite, or any other suitable indoor environment and extend toan outdoor environment. Example home 102 a may include an interface,which may include device 110, for communicating on communication links101 with local office 103, one or more external networks 109, or both.For example, device 110 may be a coaxial cable modem (for coaxial cablelinks 101), a broadband modem (for DSL links 101), a fiber interfacenode (for fiber-optic links 101), or any other suitable device orcombination of devices. In certain implementations, device 110 may be apart of, or communicatively coupled to, gateway interface device thatprovides access to a gateway 111. The gateway 111 may be, for example, awireless router, a set-top box, a computer server, or any other suitablecomputing device or combination.

The gateway interface device 111 may be any suitable computing devicefor communicating with device 110 to allow one or more other devices inexample home 102 a to communicate with local office 103, one or moreexternal networks 109, or other devices communicatively coupled thereto.The gateway 111 may include local network interfaces to providecommunication signals to user devices in or near example home 102 a,such as television 112, set-top box 113, personal computer 114, laptopcomputer 115, wireless device 116 (e.g., a wireless laptop, a tabletcomputer, a mobile phone, a portable gaming device), vehicular computingsystem 117 (e.g., a mobile computing system, navigation system, orentertainment system in an automobile, marine vessel, or aircraft) andany other suitable device

FIG. 2 illustrates general elements that can be used to implement any ofthe various computing devices discussed herein. The computing device 200may include one or more processors 201, which may execute instructionsof a computer program to perform any of the features described herein.The instructions may be stored in any type of computer-readable mediumor memory, to configure the operation of the processor 201. For example,instructions may be stored in a read-only memory (ROM) 202, randomaccess memory (RAM) 203, removable media 204, such as a Universal SerialBus (USB) drive, compact disk (CD) or digital versatile disk (DVD),floppy disk drive, or any other desired storage medium. Instructions mayalso be stored in an attached (or internal) hard drive 205. Thecomputing device 200 may include one or more output devices, such as adisplay 206 (e.g., an external television), and may include one or moreoutput device controllers 207, such as a video processor. There may alsobe one or more user input devices 208, such as a remote control,keyboard, mouse, touch screen, microphone, etc. The computing device 200may also include one or more network interfaces, such as a networkinput/output (I/O) circuit 209 (e.g., a network card) to communicatewith an external network 210. The network input/output circuit 209 maybe a wired interface, wireless interface, or a combination of the two.In some embodiments, the network input/output circuit 209 may include amodem (e.g., a cable modem), and the external network 210 may includethe communication links 101 discussed above, the external network 109,an in-home network, a provider’s wireless, coaxial, fiber, or hybridfiber/coaxial distribution system (e.g., a DOCSIS network), or any otherdesired network. Additionally, the device may include alocation-detecting device, such as a global positioning system (GPS)microprocessor, which can be configured to receive and process globalpositioning signals and determine, with possible assistance from anexternal server and antenna, a geographic position of the device.

The FIG. 2 example is a hardware configuration, although the illustratedcomponents may be implemented as software as well. Modifications may bemade to add, remove, combine, divide, etc. components of the computingdevice 200 as desired. Additionally, the components illustrated may beimplemented using basic computing devices and components, and the samecomponents (e.g., processor 201, ROM storage 202, display 206, etc.) maybe used to implement any of the other computing devices and componentsdescribed herein. For example, the various components herein may beimplemented using computing devices having components such as aprocessor executing computer-executable instructions stored on acomputer-readable medium, as illustrated in FIG. 2 . Some or all of theentities described herein may be software based, and may co-exist in acommon physical platform (e.g., a requesting entity can be a separatesoftware process and program from a dependent entity, both of which maybe executed as software on a common computing device).

One or more aspects of the disclosure may be embodied in computer-usabledata and/or computer-executable instructions, such as in one or moreprogram modules, executed by one or more computers or other devices.Generally, program modules include routines, programs, objects,components, data structures, etc. that perform particular tasks orimplement particular abstract data types when executed by a processor ina computer or other data processing device. The computer executableinstructions may be stored on one or more computer readable media suchas a hard disk, optical disk, removable storage media, solid statememory, RAM, etc. As will be appreciated by one of skill in the art, thefunctionality of the program modules may be combined or distributed asdesired in various embodiments. In addition, the functionality may beembodied in whole or in part in firmware or hardware equivalents such asintegrated circuits, field programmable gate arrays (FPGA), and thelike. Particular data structures may be used to more effectivelyimplement one or more aspects of the disclosure, and such datastructures are contemplated within the scope of computer executableinstructions and computer-usable data described herein. The variouscomputing devices, servers and hardware described herein may beimplemented using software running on another computing device.

Referring to FIG. 3 , a router 300 in communication with a plurality ofhosts 308, 310 may generate one or more messages comprising informationrelated to one or more of the identity and/or capability attributes ofthe router 300. The router 300 may hash at least a portion of themessage using at least a secret value unknown to the hosts 308, 310, andthen send the self-authenticating message 306 over the network 210(e.g., a wired or wireless network) to one or more of the hosts 308,310. The hosts 308, 310 may be self-configurable in that they may beaware of (e.g., know or store) a pre-loaded verifier value andassociated values, but not of the secret value at the router 300. Forexample, the network 210 may be an Internet Protocol (IP) networkcompatible with IPv6 that uses neighbor discovery protocol (NDP). Insuch an example, the message may be a Router Advertisement (RA) message,and the self-authenticating message 306 may be an enhanced RA message inaccordance with various aspects disclosed herein.

In some examples, when hashing at least part of the message to be aself-authenticating message 306, the router 300 may determine at least aportion of the message to be authenticated, and calculate a hashcorresponding to the portion of the message to be authenticated. Thisrouter-generated hash may be calculated using a keyed-hashing formessage authentication (HMAC) methodology (i.e., a router-HMAC). Otherapproaches to constructing a keyed message hash are contemplated for usein various examples herein. In addition to inserting the calculatedrouter-HMAC into the message, a public ephemeral value (PEV) may also beinserted.

In the preceding example, the router 300 calculates a hash value usingprocessing logic 302 (e.g., a microprocessor, an ASIC, or otherhardware). In other examples, the router 300 may delegate the step ofcalculating a hash to a separate, trusted server computing device 106 incommunication with the router 300. In any event, the calculations mayuse one or more configuration parameter values. Based on where thecalculations will take place, the configuration parameter values may bestored in memory 304 at the router 300, or may be stored elsewhere. Therouter 300 may receive, in some examples via a secure communicationchannel, the configuration parameter values and use them to generate thePEV and other values. For example, the configuration parameters maycorrespond to an identification of a key exchange algorithm, anidentification of a message digest algorithm, and an identification ofan encryption/hashing algorithm for use in communicating on the network210 between router 300 and hosts 308, 310.

The router 300 may use the one or more of the configuration parametervalues and a secret value, which is known to the router 300, but not thehost devices 308, 310, to generate various values, including, but notlimited to, a random nonce, a PEV, a session key, and/or other values.The router 300 may use one or more of the random nonce, the PEV, and thesession key to hash a portion of the message to generate aself-authenticating message 306.

Some examples of configuration parameters that may be defined,calculated, and/or recorded at the router 300 include, but are notlimited to:

TABLE 1 alg = An asymmetric key agreement protocol (e.g.,Diffie-Hellman) hash = A cryptographic hash function (e.g., SHA-256)hmac = A keyed-hash message authentication protocol (e.g., RFC 2104)rtrname = Router name used to identify the router to hosts. The namingconvention for routers may be arbitrary, and in some examples the routername may comprise all or a part of a media access control address, or“MAC” address (e.g., rtrname = 0x0050569f0d00 (Router MAC Address, e.g.00:50:56:9f:0d:00)) password = Password associated with the above routername; used by the router to produce authenticated messages (e.g.,password = password1234) privatekey = hash(salt, password) (e.g.,0xfce560be37ac70bcada5309c5f2a78be58f631de43b6a82e9099689b1e5e1365) salt= Random string used as an additional input to privatekey. The salt maybe the same size as the hash value; in this example, 256 bits to matchthe hash value of SHA-256 (e.g.,0xff3009ac12eae0e281f45f4614d6d497830e538ff83e31383df25c39daeafbc5)prime = Prime number parameter of key exchange algorithm (e.g.,0x00c395a9033ee3a9e28fab263dedf5de5ad5f4efc691a0b2acd68f61c255191fb51fac98cea5e0c4b0db2600b1db3e3509e634f7754daac2e826e1078109b8ac2d38a0aefa2a52f15563eff2e4a14000ed5a1d3b23250e4b6fdbd5391be12955323cdee5862265c21d59cd3c788170d336c584e84daf96aa09a13eaf8f5aea9643) generator = Generator parameter of key exchangealgorithm (e.g., 0×2) verifier = generator^privatekey mod prime (e.g.,0x79d26f6880abc3c490454275e8721acd596fafcac1e2d30467786a4bb68b0eacdc2733d7d4ca1973205e70a0e3c82179aacf87c4a3ac05e494a6661e7574bcea2c7207d21c16e635adca57261ec4f87eb3c33b77dc9776bec45ba6cb1bed7f43a22b6c3ace40e18fc81a1170b434638df456e22a8c747d61ca25dc8fa701a72) multiplier = hash(prime, generator) (e.g.,0xa11c8d5a656147e98512051ad0942459b8a594a466b57c0be9b9fb4b5cd11f27)staticvalue = Random string used as an additional input to PSV. Thestaticvalue may be the same size as the hash value; in this example, 256bits to match the hash value of SHA-256 (e.g.,0xda74339f9ed7f9a7ab372cfc44952f499e8270740d9c05c508bedc0a7f176ca5)public static value (“PSV”) = (multiplier * verifier +(generator^staticvalue mod prime)) mod prime (e.g.,0x56a9alac33c6916db04ccc8d0c5fa864f03ef73a4ea8314cf05be56672d7eede678a528e85e6d1a7ca5fdbfb8e214ebefee20daff53c7bc379b33a69dfe2e550a29b175f2c145fe913b3aa4b255e0665facfb1fb5414a6f077bff3b0e24f068de1460e596980d97d1da7cd5993e5f101c4979bbe0b244e0a60253bf4b907eb4f)

Some examples of configuration parameters that may be defined,calculated, and/or recorded at a host 308, 310 include, but are notlimited to:

TABLE 2 alg = An asymmetric key agreement protocol (e.g.,Diffie-Hellman) hash = A cryptographic hash function (e.g., SHA-256)hmac = A keyed-hash message authentication protocol (e.g., RFC 2104)rtrname = Router name used to identify the router to hosts. A host mayuse this information to associate specific routers with the specificconfiguration parameters set forth in a stored table. (e.g., rtrname =0x0050569f0d00 (Router MAC Address, e.g. 00:50:56:9f:0d:00)) verifier =generator^privatekey mod prime (e.g.,0x79d26f6880abc3c490454275e8721acd596fafcac1e2d30467786a4bb68b0eacdc2733d7d4ca1973205e70a0e3c82179aacf87c4a3ac05e494a6661e7574bcea2c7207d21c16e635adca57261ec4f87eb3c33b77dc9776bec45ba6cb1bed7f43a22b6c3ace40e18fc81a1170b434638df456e22a8c747d61ca25dc8fa701a72) prime = Prime number parameter of key exchangealgorithm (e.g.,0x00c395a9033ee3a9e28fab263dedf5de5ad5f4efc691a0b2acd68f61c255191fb51fac98cea5e0c4b0db2600b1db3e3509e634f7754daac2e826e1078109b8ac2d38a0aefa2a52f15563eff2e4a14000ed5a1d3b23250e4b6fdbd5391be12955323cdee5862265c21d59cd3c788170d336c584e84daf96aa09a13eaf8f5aea9643) generator = Generator parameter of key exchangealgorithm (e.g., 0×2) multiplier = hash(prime, generator) (e.g.,0xa11c8d5a656147e98512051ad0942459b8a594a466b57c0be9b9fb4b5cd11f27)staticvalue = Random string used as an additional input to PSV. Thestaticvalue may be the same size as the hash value; in this example, 256bits to match the hash value of SHA-256 (e.g.,0xda74339f9ed7f9a7ab372cfc44952f499e8270740d9c05c508bedc0a7f176ca5)public static value (“PSV”) = (multiplier * verifier +(generator^staticvalue mod prime)) mod prime (e.g.,0x56a9a1ac33c6916db04ccc8d0c5fa864f03ef73a4ea8314cf05be56672d7eede678a528e85e6d1a7ca5fdbfb8e214ebefee20daff53c7bc379b33a69dfe2e550a29b175f2c145fe913b3aa4b255e0665facfb1fb5414a6f077bff3b0e24f068de1460e596980d97d1da7cd5993e5f101c4979bbe0b244e0a60253bf4b907eb4f)

At least some of the aforementioned configuration data may be configuredand/or produced on routers 300 participating in the generation ofauthenticated router messages. In some examples, the results ofcalculated values are configured on the hosts, and not the values usedin such calculations. For example, hosts 308, 310 may be configured withthe calculated value of the verifier, but lack knowledge of theprivatekey value, which may be derived from other values, used tocompute the verifier. Such an arrangement forms aspects of an end-to-endzero-knowledge password proof for router authentication (“ZKPPRA”)solution described herein.

A portion of an illustrative script that might run, in some examples, ona router 300 in accordance with various aspects disclosed herein isshown in Table 3 below. The aforementioned illustrative script mayimport one or more Python libraries, including, but not limited to, oneor more of hashlib, random, hmac, string, sys, binascii, and/or otherlibraries. Although the example of Table 3 is illustrated in Python, thedisclosure contemplates other programming languages may be used to causeeffectively the same result.

TABLE 3 # Define SHA-256 hash function subroutine def hash(*a): returnint(hashlib.sha256(str(a)).hexdigest(), 16) # Generate Diffie-HellmanParameters (prime & generator) # Generated using “openssl dhparam -text1024” hrprime = “‘00:c3:95:a9:03:3e:e3:a9:e2:8f:ab:26:3d:ed:f5:de:5a:d5:f4:ef:c6:91:a0:b2:ac:d6:8f:61:c2:55:19:1f:b5:1f:ac:98:ce:a5:e0:c4:b0:db:26:00:b1:db:3e:35:09:e6:34:f7:75:4d:aa:c2:e8:26:e1:07:81:09:b8:ac:2d:38:a0:ae:fa:2a:52:f1:55:63:ef:f2:e4:a1:40:00:ed:5a:1d:3b:23:25:0e:4b:6f:db:d5:39:1b:e1:29:55:32:3c:de:e5:86:22:65:c2:1d:59:cd:3c:78:81:70:d3:36:c5:84:e8:4d:af:96:aa:09:a1:3e:af:8f:5a:ea:96:43‴ prime =int(“.join(hrprime.split()).replace(‘:’, ”), 16) generator = 2 #Define/calculate other variables as needed multiplier = hash(prime,generator) rtrname = “0050569f0d00” password = “password1234” salt =random.SystemRandom().getrandbits(256) privatekey = hash(salt, password)verifier = pow(generator, privatekey, prime) staticvalue =0xda74339f9ed7f9a7ab372cfc44952f499e8270740d9c05c508bedc0a7f176ca5 PSV =(multiplier * verifier + pow(generator, staticvalue, prime)) % prime

The illustrative script may be written in Python and may generateverifiers, key material, and other parameters used to demonstrate oneexample of a ZKPPRA solution. In one example demonstrating variousaspects of a ZKPPRA solution, an illustrative method may progressthrough one or more stages, including, but not limited to a preparationstage, a production stage, a validation stage, and/or other stages.

In an illustrative preparation stage, a router 300 may be configured andprepared to produce authenticated protocol data units (PDUs), as shownin FIG. 4 , using various aspects of a ZKPPRA solution including aspectsof a secure remote password protocol (“SRP”) and a PAKE protocol. SRP,by itself, is impractical for purposes of authenticating advertisementssent by a router 300 because SRP is bidirectional and point-to-point innature, whereas Router Advertisements are unidirectional and one-to-many(i.e., multicast). The ZKPPRA solution may additionally be designed tofacilitate non-interactive message authentication from router 300 tohost 308.

During setup, the router 300 and host 308 may be in possession ofparticular information. For example, the router 300 may be in possessionof at least the password and privatekey values. The host 308 may be inpossession of at least the verifier value. In some examples, the router300 and host 308 may both be in possession of values including, but notlimited to, values for:

TABLE 4 Asymmetric Key Agreement Protocol: Diffie-Hellman HashingAlgorithm: SHA-256 Keyed-hash Message Authentication Protocol: RFC 2104Prime:0x00c395a9033ee3a9e28fab263dedf5de5ad5f4efc691a0b2acd68f61c255191fb51fac98cea5e0c4b0db2600b1db3e3509e634f7754daac2e826e1078109b8ac2d38a0aefa2a52f15563eff2e4a14000ed5a1d3b23250e4b6fdbd5391be12955323cdee5862265c21d59cd3c788170d336c584e84daf96aa09a13eaf8f5aea9643L Generator: 0×2 Verifier:0x79d26f6880abc3c490454275e8721acd596fafcac1e2d30467786a4bb68b0eacdc2733d7d4ca1973205e70a0e3c82179aacf87c4a3ac05e494a6661e7574bcea2c7207d21c16e635adca57261ec4f87eb3c33b77dc9776bec45ba6cb1bed7f43a22b6c3ace40e18fc81a1170b434638df456e22a8c747d61ca25dc8fa701a72 Multiplier:0xa11c8d5a656147e98512051ad0942459b8a594a466b57c0be9b9fb4b5cd11f27LStatic Value:0xda74339f9ed7f9a7ab372cfc44952f499e8270740d9c05c508bedc0a7f176ca5LPublic Static Value:0x56a9a1ac33c6916db04ccc8d0c5fa864f03ef73a4ea8314cf05be56672d7eede678a528e85e6d1a7ca5fdbfb8e214ebefee20daff53c7bc379b33a69dfe2e550a29b175f2c145fe913b3aa4b255e0665facfb1fb5414a6f077bff3b0e24f068de1460e596980d97d1da7cd5993e5f101c4979bbe0b244e0a60253bf4b907eb4fL Salt:0xff3009ac12eac0e281f45f4614d6d497830e538ff83e31383df25c39daeafbc5L

Referring to FIG. 4 , as a result, in step 402, aspects of thecommunication between the router 300 and host 308 may be standardized.For example, encryption, message digest, and keyed-hash messageauthentication code algorithms may be standardized. In some examples,specific key exchange and message digest algorithms may be defined forall nodes participating in generation/verification of authenticatedrouter messages (or at least all nodes in a given administrative domainor community; different communities might use different algorithms, ifdesired). For purposes of illustration, the ZKPPRA solution may use:

TABLE 5 alg = Diffie-Hellman Key Agreement Method, an example of whichis defined by RFC 2631. hash = the 256-bit variant of Secure HashAlgorithm (SHA-256) message digest, an example of which is defined byRFC 6234. hmac = A keyed hash for message authentication, an example ofwhich is defined by RFC 2104.

Moreover, in step 404, configuration parameters may be generated andinstalled for participating routers. Likewise, in step 406,configuration parameters may be generated and installed forparticipating hosts. In one example, PEV and subsequent key generationsmay be performed by the router 300. The router 300 may generate a nonce(e.g., a random value of the same size as the hash value produced by theselected hash algorithm, such as the 256-bit value:

0x457cb52343ca23fe5a4f52b6c51c8461f8cc7bd49e9ed0181ccd0c22f5941659).▫Then▫therouter▫300▫may▫calculate▫a▫PEV▫(e.g.,▫generator^nonce▫mod▫prime,▫to▫output▫PEV▫=0x83aecf5fdd8e8251a6bfb2ddb834e5952360b62b759e53c7c34ad03ccafd3cd57359b030e9cc5da237550d0cdc547be2d605a37c10f94102481a5630d7342b660f2ce5c392a80fca9e431e1b0b5bba39d7272e2a47c724d9eebaa64a35651a8760a828c67aea6988c9880c1af3efef44816ed184bacbe73e87c2c633a4c11682).▫The▫router▫300▫may▫also▫calculate▫a▫scramble▫value(e.g.,▫hash(PEV,▫PSV)▫to▫output▫scramble▫=

0x658c2fce8743f876b01c743ef02ae41f5f2fecc8bd5f01dd74120f2406e8006f).▫The▫router300▫may▫use▫the▫generated▫scramble▫and▫other▫values▫to▫calculate▫S_r▫(i.e.,▫((PSV▫-▫multiplier*▫(generator^privatekey▫mod▫prime))^(nonce▫+▫scramble▫*▫privatekey)▫mod▫prime)▫to▫outputS_r▫=

0x493d48b2a34c7bbba915155bbc2f53430c06b295f1886ac30d8c1cc7de61f335d60173342259310802356cf31e533588bb688b227ab45fe06f8e64458d5ebd7d59233f8c1994e611ea9df5d41cd11628eb3045db20071fb9d2dc5b9be5f31c16738f79d0351b7cdac6ed0a1881354d820d3c9149f00dd6bb393abc644142c5c4).▫Finally,▫the▫router▫300▫may▫calculate▫a▫sessionrouterkey▫(e.g.,▫hash(S_r))▫to▫output▫a▫routerkey▫=

0xba26b5914f29f924315a30d8d3767e2663d6020788e59b554b799a74369a0f3b).

The ZKPPRA solution may make use of randomly generated nonces to, interalia, deter replay attacks and/or to ensure the presence of fresh keymaterial. Such an approach preserves that security posture to a partialextent by requiring routers 300 to similarly produce randomly generatedvalues, which may subsequently be used to produce authenticated routermessages. In some examples, the ZKPPRA solution may use per-sessionrandom nonces. This approach views the generation and/or reuse of therandom values (referred to as public ephemeral values, or “PEVs”) asconfigurable. This may provide support for high levels of router 300performance, such as immediate responses to router solicitation requestmessages. As such, PEVs may persist and be reused: never (e.g. one-timeuse, effectively a nonce); for a specific period of time (e.g. onehour); and/or for a specific number of authenticated messagetransmissions (e.g. for 1,024 Router Advertisement messages or othertypes of messages).

After the preparation stage, the router 300 may transmit authenticatedmessages (e.g., authenticated Router Advertisements or other types ofmessages) using a generated routerkey as a secret cryptographic key touse with a keyed-hash message authentication code (“HMAC”), an exampleof which is defined by RFC 2104, which is herein incorporated byreference in its entirety.

As illustrated in FIG. 5 , in one example, during the production stage,authenticated protocol data units (PDUs) may be generated. In oneexample, in step 502, nonces, public ephemeral values and session keysmay be generated. Furthermore, in step 504, the router 300 may generatenormal PDUs, such as IPv6 Router Advertisements. The router 300 maydetermine, in step 506, a portion of the PDU to be authenticated. Theportion may be some, none, or all of the appropriate parts of the PDU.The router 300 may use one or more of a nonce, PEV, and/or session keysto calculate, in step 508, a router-HMAC over the portion of the PDU tobe authenticated:

TABLE 6 Nonce:0x457cb52343ca23fe5a4f52b6c51c8461f8cc7bd49e9ed0181ced0c22f5941659LPublic Ephemeral Value:0x83aecf5fdd8e8251a6bfb2ddb834e5952360b62b759e53c7c34ad03ccafd3cd57359b030e9cc5da237550d0cdc547be2d605a37c10f94102481a5630d7342b660f2ce5c392a80fca9e431e1b0b5bba39d7272e2a47c724d9eebaa64a35651a8760a828c67aea6988c9880c1af3efef44816ed184bacbe73e87c2c633a4c11682L Scramble:0x658c2fce8743f876b01c743ef02ae41f5f2fecc8bd5f01dd74120f2406e8006fL S_r:0x493d48b2a34c7bbba915155bbc2f53430c06b295f1886ac30d8c1cc7de61f335d60173342259310802356cf31e533588bb688b227ab45fe06fBe64458d5ebd7d59233f8c1994e611ea9df5d41cd11628eb3045db20071fb9d2dc5b9be5f31c16738f79d0351b7cdac6ed0a1881354d820d3c9149f00dd6bb393abc644142c5c4L Session Key on Router:0xba26b5914f29f924315a30d8d3767e2663d6020788e59b554b799a74369a0f3bL

The router 300 may calculate the specific Router Advertisement messageoptions to be authenticated- i.e., Router Advertisement options(RAopts). The RAopts may comprise one or more Internet Control MessageProtocol (ICMPv6) options, such as a source link-layer address (e.g.,00:50:56:9f:0d:00), a maximum transmission unit value (e.g., 1280),and/or a prefix (e.g., 2001:db8:1234:5678::/64). These may berepresented as consecutive strings of hexadecimal characters or othertypes of characters. As a result, in one example, RAopts may equal:

0x1010050569f0d000501000000000500030440c0ffffffffffffffff0000000020010db8123456780000000000000000L.

Subsequently, the router 300 may generate a keyed-hash messageauthentication code (HMAC) over all RAopts (e.g., RAhmac =hmac(routerkey, RAopts); such that RAhmac =0xfd2556f76abb5ef53e020fa134aafc68d401a29ae74acf2473e2511c45fa99e).

In step 510, the router 300 may append (or insert somewhere other thanthe end of the message) an additional message authentication option thatmay contain at least:

TABLE 7 New Option Type: 0×7b (illustrative new option type) New OptionLength: 0×18 (for this example; lengths may vary) Public EphemeralValue:0x83aecf5fdd8e8251a6bfb2ddb834e5952360b62b759e53c7c34ad03ccafd3cd57359b030e9cc5da237550d0cdc547be2d605a37c10f94102481a5630d7342b660f2ce5c392a80fca9e431e1b0b5bba39d7272e2a47c724d9eebaa64a35651a8760a828c67aea6988c9880c1af3efef44816ed184bacbe73e87c2c633a4c11682L RAhmac:0xfd2556f76abb5ef53e020fa134aafc68d401a29ae74acf2473e2511c45f8a99eOptional padding to align the message authentication option to abit-aligned boundary: 0×00 as desired

For example, a RAhmac value and optional padding value may be includedin the additional message authentication option. For example, theoptional padding may be used to align the option on a predetermined(e.g., 64-bit or other number of predefined bits) boundary, or asdesired in accordance with prevailing standards. Likewise, the newoption length field may be calculated based on the cumulative length ofall fields in the option, and not necessarily a predefined value. Inother words, it may be variable based on the message digest algorithmselected and PEV.

Although the preceding example involves the creation of a new routerauthentication option type for purposes of constructing an authenticatedPDU, such an example should not constrain a ZKPPRA solution inaccordance with the disclosure. Rather, other approaches may also betaken to demonstrate that the construction of a signed routerauthentication is feasible within the ZKPPRA solution.

In step 512, the router 300 may transmit the authenticated message(e.g., router announcement) as normal. For example, an illustrativemessage authentication option may appear in a network packet capture asfollows:

-   0x7b1883aecf5fdd8e8251a6bfb2ddb834e5952360b62b759e53c7c34ad03ccafd3cd57359b0    30e9cc5da237550d0cdc547be2d605a37c10f94102481a5630d7342b660f2ce5c392a80fca9e    431e1b0b5bba39d7272e2a47c724d9eebaa64a35651a8760a828c67aea6988c9880c1af3efef    44816ed184bacbe73e87c2c633a4c11682fd2556f76abb5ef53e020fa134aafc68d401a29ae74acf2473e2511c45fBa99e00000000000000000000000000000000000000000000000000000    0000000.

As illustrated in Table 7 above, the illustrative message authenticationoption above indicates with a starting “0×7b” that it corresponds to anew option type. Furthermore, the 0 s padding appended to theillustrative message authentication option indicate that it is alignedto a bit-aligned boundary set by a new option length value.

Meanwhile, an illustrative ZKPPRA packet (including Ethernet and/or IPheaders) might appear in a network packet capture as follows:

-   333300000001005056910d0086dd6000000001003afffe80000000000000025056fffe9f0d00    ff0200000000000000000000000000018600db22000807080000000000000000010100505    69f0d000501000000000500030440c0ffffffffffffffff0000000020010db81234567800000000    000000007b1883aecf5fdd8e8251a6bfb2ddb834e5952360b62b759e53c7c34ad03ccafd3cd5    7359b030e9cc5da237550d0cdc547be2d605a37c10f94102481a5630d7342b660f2ce5c392a    80fca9e431e1b0b5bba39d7272e2a47c724d9eebaa64a35651a8760a828c67aea6988c9880c    1af3efef44816ed184bacbe73e87c2c633a4c11682fd2556f76abb5ef53e020fa134aafc68d401    a29ae74acf2473e2511c45fBa99e0000000000000000000000000000000000000000000000    00000000000000.▫For▫illustrative▫purposes▫the▫aforementioned▫packet▫may▫be▫generated    using▫a▫packet▫manipulation▫program▫(e.g.,Scapy™) and captured with    a network protocol analyzer (e.g., Wireshark™).

Referring to FIG. 6 , steps performed by the system during a validationstage are illustrated. In step 602, a host 308 may receive a PDU (e.g.,message 306) as normal. The message 306 may include a PDU of an IPv6Router Advertisement message. The host 308 may process the incoming PDU(e.g., message 306) and examine the options portion of the PDU, whichwas created in the production stage. In a ZKPPRA solution, the host 308may proceed with processing without necessarily needing to send back aPDU to the router 300. For example, in step 604, the host 308 mayretrieve the PEV, RAhmac value, and/or other values from the new messageauthentication option. In addition, the host 308 may retrieve a publicstatic value (PSV) and/or other values from the memory 304 of the host308. Collectively, these values may represent one or more of theparameters that may be used for a host to authenticate the PDU (e.g.,message 306):

TABLE 8 Public Ephemeral Value:0x83aecf5fdd8e8251a6bfb2ddb834e5952360b62b759e53c7c34ad03ccafd3cd57359b030e9cc5da237550d0cdc547be2d605a37c10f94102481a5630d7342b660f2ce5c392a80fca9e431e1b0b5bba39d7272e2a47c724d9eebaa64a35651a8760a828c67aea6988c9880c1af3efef44816ed184bacbe73e87c2c633a4c11682L RAhmac:0xfd2556f76abb5ef53e020fa134aafc68d401a29ae74acf2473e2511c45f8a99ePublic Static Value:0x56a9a1ac33c6916db04ccc8d0c5fa864f03ef73a4ea8314cf05be56672d7eede678a528e85e6d1a7ca5fdbfb8e214ebefee20daff53c7bc379b33a69dfe2e550a29b175f2c145fe913b3aa4b255e0665factb1fb5414a6f077bff3b0e24f068de1460e596980d97d1da7cd5993e5f101c4979bbe0b244e0a60253bf4b907eb4fL Verifier:0x79d26f6880abc3c490454275e8721acd596fafcac1e2d30467786a4bb68b0eacdc2733d7d4ca1973205e70a0e3c82179aacf87c4a3ac05e494a6661e7574bcea2c7207d21c16e635adca57261ec4f87eb3c33b77dc9776bec45ba6cb1bed7f43a22b6c3ace40e18fc81a1170b434638df456e22a8c747d61ca25dc8fa701a72 Prime:0x00c395a9033ee3a9e28fab263dedf5de5ad5f4efc691a0b2acd68f61c255191fb51fac98cea5e0c4b0db2600b1db3e3509e634f7754daac2e826e1078109b8ac2d38a0aefa2a52f15563eff2e4a14000ed5a1d3b23250e4b6fdbd5391be12955323cdee5862265c21d59cd3c788170d336c584e84daf96aa09a13eaf8f5aea9643L Static Value:0xda74339f9ed7f9a7ab372cfc44952f499e8270740d9c05c508bedc0a7f176ca5L

A session key may be generated in step 606. The system may determinewhich portion of the PDU to authenticate in step 608, and then in step610, the system may proceed to calculate a host HMAC value over thatportion of the PDU to be authenticated. For example, the host 308 maycalculate a scramble value (e.g., scramble =0x7f5deb9ddbe03077e0d2013128b37a02cd2b94debc0feab969ded85db99a978c) byproviding a PEV and PSV as inputs into a hash function. In addition, thehost 308 may calculate a session key using numerous values available atthe host 308. For example, the host 308 may use the generated scrambleand other values to calculate S_s = (PEV * (verifier^scramble modprime))^staticvalue mod prime. Finally, the host 308 may calculate asession hostkey (e.g., hash(S_s)) to output a hostkey =0xba26b5914f29f924315a30d8d3767e2663d6020788e59b554b799a74369a0f3b). Asample session key value may be:

TABLE 9 S_s =0x493d48b2a34c7bbba915155bbc2f53430c06b295f1886ac30d8c1cc7de61f335d60173342259310802356cf31e533588bb688b227ab45fe06fBe64458d5ebd7d59233f8c1994e611ea9df5d41cd11628eb3045db20071fb9d2dc5b9be5f31c16738f79d0351b7cdac6ed0a1881354d820d3c9149f00dd6bb393abc644142c5c4 hostkey (i.e., session key on host) =0xba26b5914f29f924315a30d8d3767e2663d6020788e59b554b799a74369a0f3b

In addition, the host 308 may calculate specific message options (e.g.,RA message options) within the received PDU (e.g., message 306) to beauthenticated (i.e., HRAopts value =

-   0x1010050569f0d000501000000000500030440c0ffffffffffffffff0000000020010db8123456    780000000000000000).

The host 308 may use one or more of the several values discussed aboveto determine an HMAC over all options (e.g., RAopts), by for example,host HMAC = hmac(hostkey, HRAopts). An illustrative value of the HMACmay be0xfd2556f76abb5ef53e020fa134aafc68d401a29ae74acf2473e2511c45f8a99e.

In step 612, the system determines whether the host HMAC valuecalculated in step 610 is the same as the router HMAC. If they are thesame, then in step 614, the host 308 may accept the PDU (e.g., message306) as authentic. Instead, if the host HMAC is not equal to the routerHMAC, then in step 616, the host may flag the PDU as unauthenticated andreject the PDU. Rejecting the PDU (e.g., message 306) may include, butis not limited to, purging the PDU from memory, re-trying the comparisonof the host HMAC to the router HMAC, quarantining the PDU in a memorystorage area, inserting an entry in a log file, and/or other activity.

In accordance with various aspects disclosed herein, although variousexamples refer to “message,” the message need not be limited to itstraditional meaning. Rather, “message” may be in the form of a protocoldata unit (PDU) or may be in the form of a plurality of fragmented datapackets that, when later assembled, serve a similar function as a singlemessage. Alternatively, “message” in some environments may be in theform of a stream of data, which when collected and collectivelyinterpreted, may serve a similar function as a message. Finally,although several examples refer to Router Advertisement messages, thedisclosure is not so limited; other message types may be used in thespirit of the features disclosed herein.

In addition, although various examples reference to IPv6 networks, thedisclosure is not so limited. Any network on which a neighbor discoveryprotocol (or functionally similar unicast, multicast, or broadcastprotocol) is being used to establish communication between two or morecommunicatively coupled devices (e.g., routers with network stacks thatcan communicate with appropriately enabled nodes) is contemplated, and“network” covers all such networks.

Furthermore, while protocols such as ICMP and NDP have been referencedin the disclosure, other similar protocols may be substituted for one ormore of the referenced protocols. In addition, in some instances theexisting, referenced protocols may be extended to support one or more ofthe features disclosed herein, such as authentication. Updates toprotocols may result in one or more modifications to the router and/orhost devices and their operating systems. Some examples of suchmodification to existing referenced protocols include creating a newtype of ICMPv6 informational message (e.g., with a “Type 150” valuetype, which is currently unassigned) similar to the “Type 134” valuetype currently in use with Router Advertisement messages. Alternatively,a new code could be assigned to an existing message type or a newmessage type. For example, currently “Code 0” is used for RouterAdvertisement messages, but a new code value could be assigned formessages enhanced with one or more features disclosed herein. In yetanother alternative, a new option may be added to the list of existingoptions for a given message type. For example, several options forRouter Advertisement messages include a Source Link-Layer Address(Option Type 1) and Prefix Information (Option Type 3). A new optiontype value may be assigned for messages 306 sent in accordance withvarious features disclosed herein. For example, Option Type 123, whichis currently unassigned, of Router Advertisement messages may bereserved for messages 306 sent by a router 300 in accordance withvarious aspects disclosed herein.

In addition, in some examples, the router 300 and hosts 308, 310described herein may each be preloaded with configuration data tofacilitate a ZKPPRA solution, as described herein. Examples include, butare not limited to, IT management frameworks, such as a group policy(e.g., Active Directory Group Policy for Microsoft Windows operatingsystems), mobile device management (“MDM”) frameworks for managingconfiguration profiles for iOS devices like the iPhone, iPad, etc.,connection manager frameworks, such as Wi-Fi Alliance’s Passpoint™initiative, and others. Furthermore, although an asymmetric key exchangeprotocol, such as Diffie-Hellman Key Agreement (as defined by RFC 2631,which is herein incorporated by reference in its entirety and a copy ofwhich is being filed in an Information Disclosure Statement concurrentwith this application filing), has been be described to supportauthentication of Router Advertisement messages, the disclosure is notso limited. Other protocols may be substituted or integrated into theprotocol described herein while remaining within the spirit of thedisclosure. Likewise, a cryptographically strong digest algorithm, suchas the 256-bit variant of Secure Hash Algorithm (SHA-256) (as defined byRFC 6234, which is herein incorporated by reference in its entirety anda copy of which is being filed in an Information Disclosure Statementconcurrent with this application filing), has been described to supportauthentication of Router Advertisement messages, the disclosure is notso limited.

Aspects of the disclosure have been described in terms of illustrativeembodiments thereof. While illustrative systems and methods as describedherein embodying various aspects of the present disclosure are shown, itwill be understood by those skilled in the art, that the disclosure isnot limited to these embodiments. Modifications may be made by thoseskilled in the art, particularly in light of the foregoing teachings.For example, each of the features of the aforementioned illustrativeexamples may be utilized alone or in combination or subcombination withelements of the other examples. For example, any of the above describedsystems and methods or parts thereof may be combined with the othermethods and systems or parts thereof described above. For example, oneof ordinary skill in the art will appreciate that the steps illustratedin the illustrative figures may be performed in other than the recitedorder, and that one or more steps illustrated may be optional inaccordance with aspects of the disclosure. It will also be appreciatedand understood that modifications may be made without departing from thetrue spirit and scope of the present disclosure. The description is thusto be regarded as illustrative instead of restrictive on the presentdisclosure.

It is noted that various connections are set forth between elements inthe following description. These connections are described in generaland, unless specified otherwise, may be direct or indirect; thisspecification is not intended to be limiting in this respect.

1. A method comprising: generating, by a network router, a routeradvertisement message; hashing, by the network router and using a secretvalue of the network router, at least a portion of the routeradvertisement message; sending, to a plurality of host devices, aself-authenticating message comprising: the router advertisementmessage; and the hashed at least a portion of the router advertisementmessage; and communicating with the plurality of host devices after thehost devices authenticate the self-authenticating message.
 2. The methodof claim 1, wherein the hashing comprises encryption.
 3. The method ofclaim 1, wherein the hashing comprises hashing a maximum transmissionunit value of the router advertisement message.
 4. The method of claim1, wherein the self-authenticating message comprises a code indicatingthat the self-authenticating message comprises a hash of the at leastthe portion of the router advertisement message.
 5. The method of claim1, wherein the self-authenticated message is generated withoutpreviously receiving information from the host devices.
 6. A methodcomprising: receiving, by a host device and from a network router, aself-authenticating message, wherein the self-authenticating message:was sent to a plurality of host devices; comprises a routeradvertisement message; and comprises a first hash value; generating asecond hash value based on at least a portion of the routeradvertisement message; and based on comparing the first hash value andthe second hash value: authenticating the network router; andcommunicating with the network router.
 7. The method of claim 6, whereingenerating the second hash value comprises encryption.
 8. The method ofclaim 6, wherein the generating the second hash value comprises hashinga maximum transmission unit value of the router advertisement message.9. The method of claim 6, wherein the self-authenticating messagecomprises a code indicating that the self-authenticating messagecomprises a hash of the at least the portion of the router advertisementmessage.
 10. The method of claim 6, wherein the self-authenticatingmessage is received from the network router without the host devicepreviously sending information to the network router.
 11. One or morenon-transitory, computer-readable media storing instructions that, whenexecuted, cause: generating, by a network router, a router advertisementmessage; hashing, by the network router and using a secret value of thenetwork router, at least a portion of the router advertisement message;sending, to a plurality of host devices, a self-authenticating messagecomprising: the router advertisement message; and the hashed at least aportion of the router advertisement message; and communicating with theplurality of host devices after the host devices authenticate theself-authenticating message.
 12. The one or more non-transitory,computer-readable media of claim 11, wherein the instructions, whenexecuted, cause the hashing by causing encryption.
 13. The one or morenon-transitory, computer-readable media of claim 11, wherein theinstructions, when executed, cause the hashing by causing hashing of amaximum transmission unit value of the router advertisement message. 14.The one or more non-transitory, computer-readable media of claim 11,wherein the self-authenticating message comprises a code indicating thatthe self-authenticating message comprises a hash of the at least theportion of the router advertisement message.
 15. The one or morenon-transitory, computer-readable media of claim 11, wherein theinstructions, when executed, cause the network router to generate theself-authenticated message without previously receiving information fromthe host devices.
 16. One or more non-transitory, computer-readablemedia storing instructions that, when executed, cause: receiving, by ahost device and from a network router, a self-authenticating message,wherein the self-authenticating message: was sent to a plurality of hostdevices; comprises a router advertisement message; and comprises a firsthash value; generating a second hash value based on at least a portionof the router advertisement message; and based on comparing the firsthash value and the second hash value: authenticating the network router;and communicating with the network router.
 17. The one or morenon-transitory, computer-readable media of claim 16, wherein theinstructions, when executed, cause the generating the second hash valueby causing encryption.
 18. The one or more non-transitory,computer-readable media of claim 16, wherein the instructions, whenexecuted, cause the generating the second hash value by causing hashingof a maximum transmission unit value of the router advertisementmessage.
 19. The one or more non-transitory, computer-readable media ofclaim 16, wherein the self-authenticating message comprises a codeindicating that the self-authenticating message comprises a hash of theat least the portion of the router advertisement message.
 20. The one ormore non-transitory, computer-readable media of claim 16, wherein theinstructions, when executed, cause the host device to receive theself-authenticating message from the network router without the hostdevice previously sending information to the network router.
 21. Anetwork router comprising: one or more processors; and memory storinginstructions that, when executed by the one or more processors,configure the network router to: generate a router advertisementmessage; hash, using a secret value of the network router, at least aportion of the router advertisement message; send, to a plurality ofhost devices, a self-authenticating message comprising: the routeradvertisement message; and the hashed at least a portion of the routeradvertisement message; and communicate with the plurality of hostdevices after the host devices authenticate the self-authenticatingmessage.
 22. The network router of claim 21, wherein the instructions,when executed by the one or more processors, configure the networkrouter to hash the at least a portion of the router advertisementmessage by encryption.
 23. The network router of claim 21, wherein theinstructions, when executed by the one or more processors, configure thenetwork router to hash the at least a portion of the routeradvertisement message by hashing of a maximum transmission unit value ofthe router advertisement message.
 24. The network router of claim 21,wherein the self-authenticating message comprises a code indicating thatthe self-authenticating message comprises a hash of the at least theportion of the router advertisement message.
 25. The network router ofclaim 21, wherein the instructions, when executed by the one or moreprocessors, configure the network router to generate theself-authenticated message without previously receiving information fromthe host devices.
 26. A host device comprising: one or more processors;and memory storing instructions that, when executed by the one or moreprocessors, configure the host device to: receive, from a networkrouter, a self-authenticating message, wherein the self-authenticatingmessage: was sent to a plurality of host devices; comprises a routeradvertisement message; and comprises a first hash value; generate asecond hash value based on at least a portion of the routeradvertisement message; and based on comparing the first hash value andthe second hash value: authenticate the network router; and communicatewith the network router.
 27. The host device of claim 26, wherein theinstructions, when executed by the one or more processors, configure thehost device to generate the second hash value by encryption.
 28. Thehost device of claim 26, wherein the instructions, when executed by theone or more processors, configure the host device to generate the secondhash value by hashing a maximum transmission unit value of the routeradvertisement message.
 29. The host device of claim 26, wherein theself-authenticating message comprises a code indicating that theself-authenticating message comprises a hash of the at least the portionof the router advertisement message.
 30. The host device of claim 26,wherein the instructions, when executed by the one or more processors,configure the host device to receive the self-authenticating messagefrom the network router without the host device previously sendinginformation to the network router.
 31. A system comprising: a hostdevice and a network router, wherein the network router is configuredto: generate a router advertisement message; hash, using a secret valueof the network router, at least a portion of the router advertisementmessage; send, to a plurality of host devices, a self-authenticatingmessage comprising: the router advertisement message; and the hashed atleast a portion of the router advertisement message; and communicatewith the plurality of host devices after the host devices authenticatethe self-authenticating message, and wherein the host device isconfigured to receive the self-authenticating message.
 32. The system ofclaim 31, wherein the network router is configured to hash the at leasta portion of the router advertisement message by encryption.
 33. Thesystem of claim 31, wherein the network router is configured to hash theat least a portion of the router advertisement message by hashing of amaximum transmission unit value of the router advertisement message. 34.The system of claim 31, wherein the self-authenticating messagecomprises a code indicating that the self-authenticating messagecomprises a hash of the at least the portion of the router advertisementmessage.
 35. The system of claim 31, wherein the network router isconfigured to generate the self-authenticated message without previouslyreceiving information from the host devices.
 36. A system comprising: ahost device and a network router, wherein the host device is configuredto: receive, from the network router, a self-authenticating message,wherein the self-authenticating message: was sent to a plurality of hostdevices; comprises a router advertisement message; and comprises a firsthash value; generate a second hash value based on at least a portion ofthe router advertisement message; and based on comparing the first hashvalue and the second hash value: authenticate the network router; andcommunicate with the network router, and wherein the network router isconfigured to send the self-authenticating message to the host device.37. The system of claim 36, wherein the host device is configured togenerate the second hash value by encryption.
 38. The system of claim36, wherein the host device is configured to generate the second hashvalue by hashing a maximum transmission unit value of the routeradvertisement message.
 39. The system of claim 36, wherein theself-authenticating message comprises a code indicating that theself-authenticating message comprises a hash of the at least the portionof the router advertisement message.
 40. The system of claim 36, whereinthe host device is configured to receive the self-authenticating messagefrom the network router without the host device previously sendinginformation to the network router.